User settings for policy-based automations are typically fairly “hard-coded” and relatively inflexible. They are composed of many individual rules, with no high-level or collective means for adjusting them. For instance, SAN File System provides automated initial file placement via a multiplicity of rules. In a system having thousands of rules which requires periodic adjustment (as an aside, mature policy-based systems such as DFSMS can have more than ten thousand rules), a user would be required to change settings in hundreds of rules at a time. This routine and necessary maintenance would be both tedious and error-prone.
Those skilled in the art have been considering adding higher-level service class rules, which would help, but even with these there will not be a single easy and high-level way for users to exercise a degree of control over operations by, for example, manually “tweaking” the overall policy optimization; enabling the manually “tweaked” policy optimization; and disabling the manually “tweaked” policy optimization. Thus, there are no current means for seeing what performance gains are available through manual optimization of ordinarily automated controls.
Other problems with automated systems concern their difficulty in establishing user trust and the need for providing means to enable users to effectively monitor the automated systems. It can take many years for users to develop trust in a system. Automated systems with a multitude of possible control settings can be very hard to monitor and maintain—such systems are often essentially neglected by software vendors and thought to be “black boxes” by users.
In addition to the problems encountered in rule-based automated systems there are also problems encountered in situations where the selection of settings for a product require tuning. For example, it is often unclear whether it is best to provide user control over the tuning of parameters (for example, for various heartbeat intervals, wait periods, retries and buffer sizes), or to automate them completely in a manner invisible to users. Weighing in on the side of user control is that users typically prefer control, especially for new products that they do not trust yet. User control also helps users to learn how the system works and therefore to truly understand the system. Weighing against surfacing user control for tuning settings is that some users might choose sub-optimal settings.
When users are polled, they overwhelmingly demand to have manual overrides to automations. They also want such overrides to be easily selected and quickly implemented. Note that in the highly-evolved user interface paradigm of automobiles that manual overrides have evolved to be easily selected and quickly implemented. For example, to disable active cruise control, a driver just taps the brakes or pushes the off button. In an automatic transmission, a driver uses the multi-function gear selector to quickly and easily shift an automobile from drive to second gear when approaching a steep downslope.
Accordingly, those skilled in the art desire the ability to exercise a measure of control over automated processes that ordinarily control selection of one or more values for one or more parameters of a computer system resource. In one aspect, those skilled in the art desire the ability to disable momentarily the automated process selecting values for the plurality of settings, so that the user can manually adjust a value indicated by a graphical advisor. By making adjustments to the value indicated by the graphical advisor, the user also effectively would be changing one or more settings for the computer system resource. A system implemented in this way would make it far easier for a user to change hundreds or perhaps thousands of settings selected for the computer system resource.
In other situations, those skilled in the art may not want direct control over the plurality of settings selected for the computer system resource. In these situations, the user may desire that the automated process ordinarily selecting the settings for the computer system resource continue to operate, but be subject to a measure of control by the user. For example, oftentimes it is costly in terms of system resources to spawn numerous small-scale changes called for by the automated process throughout a complex computer system resource like a networked database. In such situations, the user may desire that the automated process continue to make large-scale changes to the settings required by work loads that vary in a predictable manner over a daily period, but ignore small-scale changes required by minute moment-to-moment variations in load conditions. In other situations where load conditions spike and then return to a nominal value, the user may desire that the automated process respond to small-scale variations in load conditions but ignore large-scale changes.
In summary, those skilled in the art thus desire controls that enable users to exercise some measure of control over how an automated process makes changes to one or more settings of a computer system resource.